The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
The development and deployment of internet of things (IoT) devices has proceeded with remarkable speed in the past several years. IoT devices are diverse, including everything from controllers of industrial equipment to smart watches and personal activity monitors. However, security infrastructure has not kept pace with the huge number and wide use of these devices. Some analysts estimate that billions of such devices will be operating and connected to internetworks within a few years, but there is presently no effective security architecture that can efficiently permit IoT devices to be secured, yet readily usable. Key constraints in this technical field have included limited processing power, limited memory, and limited or absent user interface elements. All these characteristics of IoT devices make them difficult to integrate into existing client-server security systems. At the same time, misuse of IoT devices could be catastrophic by permitting an attacker or unauthorized user to gain control of industrial equipment or other systems that have embedded IoT devices.
Traditionally, client computing devices with internet access can connect to enterprise server computers, which provide identity and access management (IAM) services for managing, validating, and controlling user access. Almost without exception, networks that permit access from desktop computers or mobile computing devices of end users have placed all principal security apparatus at the server computer. For example, a user who wants access to an online account can use a computer with internet connectivity to access a website with a login page and input identity information, such as a username and password. Once a server computer validates the identity information, policies control the amount of access any particular device has so that the user can access their own account without accessing any other data.
This traditional approach often uses hardcoded credential associated with the enterprise firmware. For example, some enterprise devices within an enterprise system are built with a default administrative account and password hard-coded into the enterprise device. This default account and password is publicly available and identical for each device of the same model and manufacture. Malicious attacks may target these devices and implement a hard reset, which would reset the device credential back to its factory setting. The malicious attacker would then have unfettered access to the enterprise device and all identity information associated with the enterprise device. Therefore, a security breach of an enterprise device on a system could compromise the security of the entire system if a malicious attack successfully accessed the identity information for all users and applications.
Furthermore, various IoT devices often use communication protocols that lack access regulation. For example, devices may use a Message Queue Telemetry Transport (MQTT) protocol to exchange messages about different topics. Based on the design of the MQTT protocol, any device with access to a MQTT message broker may have full access to all topics, which presents a security risk if some devices that should be properly denied access to particular topics are instead given access. Implementing an authentication system that accommodates the various protocols used by different devices presents yet another infrastructure challenge as a variety of different IoT devices become more widely-used. For example, while some devices use the MQTT protocol to communicate, other may use the Modbus protocol. Traditionally, the burden of accessing enterprise devices that use different protocols is placed on the client device such at the client device would need to be programmed to accommodate every protocol used by the various enterprise devices. This heavily strains the processing resources of the client device.
Thus, there is a need for a single authentication portal that can accommodate devices that use different network protocols across multiple OSI layers and mitigates the security risks of devices that use hardcoded credentials.